First, an explanation will be given for a case wherein a communication node is in a multihomed state. Furthermore, it is assumed that a multihomed state described herein indicates a state wherein a specific communication node maintains a plurality of IP addresses (hereinafter also referred to simply as addresses) configured based on different prefixes.
There are, roughly, the two following cases wherein a communication node is in a multihomed state.
First case: case wherein a network to which a communication node is connected is transmitting (advertising) a plurality of different prefixes.
Second case: case wherein a communication node includes a plurality of interfaces, and these interfaces are all connected to different networks, at the same time.
The first case (the case wherein a network to which a communication node is connected is transmitting (advertising) a plurality of different prefixes) could happen when, for example, a network, to which a communication node is connected, belongs to a site that is connected to a plurality of Internet service providers (ISPs) (when the site is in a multihomed state). In this case, since based on the prefixes owned by the individual ISPs, a plurality of prefixes are transmitted across the network belonging to the site and this enables the communication node connected to the network to maintain, as addresses available on the network, a plurality of addresses having different prefixes. That is, in this case, whether the communication node maintains a plurality of addresses is determined and depends on the configuration of the site. Additionally, even when the site is not in a multihomed state, the site can transmit a plurality of effective prefixes across the network.
Further, in the second case (the case wherein a communication node includes a plurality of interfaces and these interfaces are all connected to different networks, at the same time), since prefixes are transmitted by destination networks respectively connected to the individual interfaces of the communication node, at least one usable IP address for each network is allocated for each interface. Therefore, for the communication node, overall, a plurality of addresses having different prefixes are allocated for the communication node. That is, in this case, whether the communication node maintains a plurality of addresses is determined by the configuration of the communication node.
Furthermore, the communication node can also be in a multihomed state in a case wherein the first and the second cases are combined, such as one wherein a communication node including a plurality of interfaces is connected to a network that is transmitting (advertising) a plurality of different prefixes, or a case wherein at least one of the interfaces of a communication node that includes a plurality of interfaces is connected to a network that is transmitting addresses for a plurality of different networks (first case).
At present, according to the IETF MULTI6 Working Group (http://www.ietf.org/html.charters/multi6-charter.html), a method for providing an additional new layer between a network layer and an upper layer or a lower layer, or providing an additional new sub-layer to a network layer to map a plurality of IP addresses in an identifier of the upper layer, and a method for permitting a transport layer to handle a plurality of IP addresses are proposed as methods whereby a communication node in a multihomed state can perform communication using a plurality of IP addresses (see non-patent documents 1 and 2 below). It should be noted that the above methods for managing a plurality of IP addresses are those for maintaining a connection to a transport layer.
According to the method for controlling these multiple IP addresses to handle the multihomed state, both the transmission side and the reception side perform the processes in order to employ a plurality of addresses, for example, exchange of address information and selection of a source address and a destination address.
Next, a mobile IP (hereinafter also referred to as an MIP; see non-patent document 3 below) will be briefly described. For a communication node (an MN: a Mobile Node. It should here be noted that generally an MN represents both an MH (Mobile Host) and an MR (Mobile Router)) defined according to the mobile IP, at least one HoA is allocated by the home network of the communication node. When this MN has moved to another sub-network (a foreign network), the MN obtains at least one CoA (Care-of Address) on the current network, and transmits to an HA (Home Agent) present on the home network of the MN, information (binding information) that indicates a correlation between the obtained CoA and the HoA allocated via the network. Thus, the HA can receive, by proxy, a packet addressed to the HoA of the MN, and can transfer it to the CoA, so that the MN can receive the packet transmitted to the HoA even though the MN is present in the foreign network.
As defined in non-patent document 3, the address relationship the MN can register for the HA is a one-to-one correspondence of the HoA and the primary CoA, and this information is reported as a binding update message transmitted by the MN.
According to the mobile IP, binding information for the MN is designed so as to maintain a plurality of CoAs that can register with the HA, and is information indicating a correlation between one primary CoA, which is selected from a plurality of CoAs, and one HoA. That is, even when the MN includes a plurality of CoAs, only one CoA can be registered with the HA. As a result, when the MN transmits a plurality of binding update messages in order to correlate a plurality of CoAs with one HoA, the HA regards this as simple CoA updating, and as a result, the HA maintains only the binding information that was received as the last binding update message.
To resolve this problem, a method for registering a plurality of CoAs relative at a single HoA is disclosed in non-patent document 4 below. Using this method, the MN can register, as binding information, a relation between a single HoA and a plurality of CoAs (a one-to-multiple relation).
On the other hand, in a case wherein a home network is in a site multihomed state, or in a case wherein a plurality of home networks are allocated to the MN, when the MN maintains a plurality of HoAs, the MN correlates one primary CoA with each of the individual HoAs, and registers information indicating a correlation between the HoAs and the primary CoAs with the HAs that manage the respective HoAs. At this time, when the HAs that manage the HoAs differ from each other, the MN transmits a binding update message to the individual HAs that manage the HoAs, and as a result, the individual HAs prepare a binding cache.
On the other hand, when there is only one HA to a plurality of HoAs, the MN transmits to the HA binding update messages concerning the individual HoAs. Upon receiving a update message, the HA generates and manages binding caches in consonance with the binding update messages, without being aware that these binding caches are related to binding update messages transmitted by the same MN. Thus, since correlating of these binding caches is not performed, the HA has no perception of the binding caches that are provided by the same MN.
As explained above, the multihoming function of the communication node is different from the mobile IP function, and is employed both for a fixed node and a mobile node. However, when the mobile IP is applied for a communication node that performs multihoming, a plurality of HoAs and CoAs maintained by the MN are included in a plurality of IP addresses to be managed by a multihoming controller. This is because both the function of the multihoming controller and the mobile IP function depend on the configuration of layers, and generally, the multihoming controller is located higher than the mobile IP. When the MN maintains a plurality of HoAs and CoAs, the mobile IP transmits, to higher components, a notification concerning these HoAs and CoAs, and accordingly, the multihoming controller processes these HoAs and CoAs.
As described above, the feature of the MN that includes both the function of the multihoming controller and the mobile IP function is that, when a plurality of HoAs are allocated to the MN, the HoAs are managed by the multihoming controller.
Another method for selecting a source address when a host maintains a plurality of IP addresses is defined in non-patent document 5 below. Here, rules used for the selection of a source address are defined, and “Prefer Home Address” is present in the rules. This “Prefer Home Address” is a rule that, among a plurality of addresses, an address (HoA) connected to the home network is more preferential than a CoA.
[Non-Patent Document 1] Erik Nordmark, Marcelo Bagnulo, “Multihoming L3 Shim Approach”, draft-ietf-multi6-13shim-00.txt, 10 Jan. 2005.
[Non-Patent Document 2] R. Stewart, Q. Xie, “Stream Control Transmission Protocol”, RFC2960, October 2000.
[Non-Patent Document 3] Johnson, D. B., Perkins, C. E., and Arkko, J., “Mobility Support in IPv6”, RFC3775, June 2004.
[Non-Patent Document 4] Ryuji Wakikawa, Keisuke Uehara, Thierry Ernst, “Multiple Care-of Addresses Registration” IETF Internet Draft: draft-wakikawa-mobileip-multiplecoa-03.txt, 19 Jun. 2004.
[Non-Patent Document 5] R. Draves, “Default Address Selection for Internet Protocol version 6 (IPv6)”, RFC3484, February 2003.
However, since the multihoming controller is so designed that it is not concerned with the moving of the communication node, and only manages a plurality of addresses maintained by the communication node, the multihoming controller does not recognize that the address managed by the multihoming controller is an HoA or a CoA for the mobile IP, since the communication node has moved. Therefore, for example, the rule described in non-patent document 5 can not be directly employed for the multihoming controller.
Therefore, assume that the MN maintains a plurality of addresses because the site whereat the home network of the MN is located is currently performing multihoming, or because a plurality of home networks are allocated for the MN at the same time. In this case, since the multihoming controller that manages these addresses is separated from an MIP layer (hereinafter referred to as an MIP controller) that includes a function related to a mobile IP, when the multihoming controller selects, for example, a specific address as a source address, actually, as the MN is moving, the selected address is changed to that for the HoA of the mobile IP. Further, in a case wherein a CoA obtained at a connection destination is allocated for the interface, the address the multihoming controller has selected as a source address no longer accurately indicates the current location of the MN.
That is, although a new condition has been established by the movement of the MN, the multihoming controller is not aware of this, and based only on the policy of the multihoming controller, selects, as a source address, one of multiple addresses maintained by the multihoming controller. According to this configuration, it is not possible to say that the actual situation of the MN does not correspond to the address selection performed by the multihoming controller, and a condition that should be considered from the viewpoint of mobility is not referred to at all.
As a result, in the case of the transmission of a packet via the HA by the MN, the transmission is performed through the HA that is present on a network to which a home address selected by the multihoming controller is allocated, and selection of the HA is not performed while the states of a plurality of HAs are considered. Thus, a packet is transmitted using an inappropriate address that has been selected, and there are problems in that various defects, such as delays and packet losses, may occur.
While referring to FIG. 29, an explanation will be given for the above described conventional problem that, in a case wherein both the mobile IP and the protocol that achieves multihoming are mounted in one MN, a mobility condition that occurs as the MN is moving is not appropriately reflected. FIG. 29 is a schematic diagram showing a first example internal arrangement of an MN to explain a problem related to the prior art.
An MIP controller 1920 and a multihoming controller 1930 mounted in an MN are shown in FIG. 29. Further, the presence of the MIP controller 1920 indicates that a protocol, such as an MIP, to provide mobility management is mounted in the MN, and the presence of the multihoming controller 1930 indicates that a protocol that performs multihoming is also mounted in the MN.
Assume, for example, that the MN is in the multihomed state, and the multihoming controller 1930 manages two addresses (Addr1 and Addr2). At this time, suppose that the MN moved from its home network to a foreign network, and has obtained a CoA (MN1.CoA1) correlated with Addr1 (=MN1.HoA1) and a CoA (MN1.CoA2) correlated with Addr2 (=MN1.HoA2).
However, the multihoming controller 1930 is not aware that the two managed addresses (Addr1 and Addr2) have been changed to HoAs for the MN, and selects an address to be used for communication with a predetermined communication partner, not knowing that the MN has moved. For example, when the multihoming controller 1930 has selected Addr1 of the two addresses (Addr1 and Addr2), the multihoming controller 1930 transmits, to the MIP controller 1920, a notification indicating that Addr1 is the address to use. Upon receiving this notification, the MIP controller 1920, which includes only a function for generating a packet using an address that has been transmitted by the multihoming controller 1930, designates, as a source address, MN1.HoA1, which is the same as Addr1, or MN1.CoA1, which corresponds to MN1.HoA1, and transmits a packet. Therefore, according to this problem encountered with the prior art, in a case wherein a condition exists such that, as the MN moves, MN1.HoA2 or MN1.CoA should be designated as a source address for a packet is established, and an address selected by the multihoming controller is designated as a source address for a packet.
A problem that has been encountered in a case wherein the multihoming controller is located higher than the mobile IP is shown in FIG. 29. Likewise, in this case, as shown in FIG. 30, wherein a multihoming controller is located lower than a mobile IP, appropriate cooperation for address selection is not available between an MIP controller and the multihoming controller, and a resulting problem is that a condition (an address selection condition) due to the multihomed state of an MN is not appropriately reflected. This problem will now be described while referring to FIG. 30. FIG. 30 is a schematic diagram showing a second example MN internal arrangement for explaining a problem related to the prior art.
An MIP controller 1920 and a multihoming controller 1930 mounted in an MN are shown in FIG. 29. It should be noted that, as described above, the MIP controller 2020 is located higher than the multihoming controller 2030 in FIG. 30.
Assume, for example, that the MN is in the multihomed state and the multihoming controller 2030 is managing two addresses (Addr1 and Addr2). In addition, the multihoming controller 2030, located lower than the MIP controller 2020, is designed to manage an IP address (also called a locator, according to a technique related to multihoming) allocated to an interface, in correlation with a ULID (Upper-Layer Identifier), and the MIP controller 2020 is designed to correlate and manage home addresses in correlation with the ULIDs. Here, suppose that the multihoming controller 2030 holds a correlation between Addr1 (=MN1.CoA1) and ULID1 and a correlation between Addr2 (=MN1.CoA2) and ULID2, and the MIP controller 2920 holds a correlation between MN1.HoA1 and ULID1 and a correlation between MN1.HoA2 and ULID2.
Further, the multihoming controller 2030 can manage a plurality of ULIDs. The multihoming controller 2030 can also manage one ULID in correlation with a plurality of addresses, and for example, in FIG. 30, can manage ULID1 by correlating it with a plurality of addresses that, at the same time, differ from Addr1. In this case, upon receiving an instruction to use ULID1 in the upper layer, for example, the multihoming controller 2030 can select one of multiple addresses correlated with ULID1.
At this time, in a case wherein, for example, an environment is changed as the MN moves, the MIP controller 2020 employs a condition (a mobility condition) that is due to the mobility attained by the MIP controller 2020 to select an address for use in communication with a predetermined communication partner. For example, when the MIP controller 2030 selects MN1.HoA1, one of the two addresses (MN1.HoA1 and MN1.HoA2), the MIP controller 2030 transmits, to the multihoming controller 2030, a notification indicating that ULID1 is an address to be used. Based on ULID1, the multihoming controller 2030, which includes only a function for selecting one or a plurality of addresses (Addr1 in the example in FIG. 30) correlated with ULID1, designates Addr1 (MN1.CoA1) as a source address, and transmits a packet. Therefore, according to the prior art, the problem is that, even in a case wherein MN1.CoA2 should be designated as a source address for a packet, in accordance with an address selection condition that is due to multihoming, only an address limited to the ULID that is selected by the MIP controller 2020 is designated as a source address for a packet.